Subject: Revised DLSw Multicast Proposal - For AP Status Approval

From: David Bryant/HQ/3Com <[email-masked]>
Date: 25 Jun 96 19:14:14 EDT

David Bryant 3Com Corp           October 1995
Mike Redden  Proteon Inc           Revised 7/96
Paul Britton  Data Connection Ltd.

A submission to the APPN Implementers Workshop
Draft Proposal for Approved Pages Status
at 
AIW 11 
July 1996, NC

DLSw Multicast Protocol Enhancements
1. Background 
2. Intent 
3. Scope 
4. Overview 
5. Multicast Groups and Addressing 
5.1 Using Multicast Groups 
6. DLSw Message Transports 
6.1 TCP/IP Connections on Demand 
6.2 UDP Datagrams 
6.2.1 UDP SSP Packet Handling 
6.2.2 Unicast UDP Datagrams 
6.2.3 Multicast UDP Datagrams 
7. Migration Support 
7.1 Capabilities Exchange 
7.2 Connecting to down-level nodes 
7.3 Communicating with down-level nodes 
8. SNA Support 
8.1 Address Resolution 
8.2 Explorer frames 
8.3 Example SNA SSP Message Sequence 
8.4 Circuit Setup 
8.5 UDP Reliability 
8.5.1 Retries 
9. NetBIOS 
9.1 Address Resolution 
9.2 Circuit Setup 
9.3 Example NetBIOS SSP Message Sequence 
9.4 Multicast Reliability and Retries 
10. Sequencing 
11. Frame Formats 
11.1 Multicast Capabilities Control Vector 
11.2 UDP Packets 

Background
RFC 1795 specifies an AIW standard for the Switch to Switch Protocol (SSP) of 
Data Link Switching (DLSw).   Through implementation and installation 
experiences, vendors have become increasingly more concerned with the 
scalability of DLSw protocols in large networking situations.  Accordingly, a 
DLSw Scalability group has been established within the AIW to define a set of 
DLSw protocol enhancements for the purpose of improving DLSw scalability. 

It is assumed that the reader is familiar with DLSw and RFC 1795.  No effort 
has been made to explain those protocols or associated terminology.  Note: 
Throughout this document the acronym SSP has been used interchangeably to refer 
to both the switch to switch protocol of DLSw and the set of state machines 
which implement the protocol.  However, the endpoint of an SSP message exchange 
is referred to as a DLSw.

Intent

This document defines a set of SSP protocol enhancements to RFC 1795 which will 
improve the scalability of DLSw.  These enhancements are designed to be fully 
backward compatible with existing  RFC 1795 implementations.   Once completed 
and approved within the AIW, it is the intent of the DLSw Scalability group  to 
submit these enhancements to the IETF in the form of an informational RFC.  As 
a compatible set of optional enhancements to RFC 1795, this document does not 
replace or supersede RFC 1795. 

Scope

The DLSw Scalability group of the AIW has identified a number of scalability 
issues associated with existing DLSw protocols as defined in RFC 1795: 

z Administration
 
 RFC 1795 implies the need to define the transport address of all peer DLSws at 
each DLSw.  In highly meshed situations (such as those often found in NetBIOS 
networks), the resultant administrative burden is undesirable.
 
z Address Resolution
 
 RFC 1795 defines point to point TCP (or other reliable transport protocol) 
connections between each DLSw.  When attempting to discover the location of an 
unknown resource, a DLSw sends an address resolution packet to each partner 
DLSw over these connections.  In highly meshed configurations, this can result 
in a very large number of packets in the transport network.  Although each 
packet is sent individually to each DLSw partner, they are each identical in 
nature.  Thus the transport network is burdened with excessive numbers of 
identical packets.  Since the transport network is most commonly a wide area 
network where bandwidth is considered a precious resource, this packet 
duplication is undesirable. 

z Broadcast Packets
 
 In addition to the address resolution packets described above, RFC 1795 also 
propagates NetBIOS broadcast packets into the transport network.  The UI frames 
of NetBIOS are sent as LAN broadcast packets and RFC 1795  DLSws propagate 
these packets over the point to point transport connections to each DLSw 
partner.  In the same manner as above, this creates a large number of identical 
packets in the transport network.  This is also considered undesirable.  And 
because NetBIOS UI frames can be sent by applications, it is difficult to 
predict or control the rate and quantity of such traffic.   This compounds the 
undesirability of the existing RFC 1795 propagation method for these packets.
 
z TCP (transport connection) Overhead
 
  As defined in RFC 1795, each DLSw maintains a transport connection to its 
peer DLSw partners.  Each transport connection guarantees in order packet  
delivery.   This is accomplished using acknowledgment and sequencing algorithms 
which require both CPU and memory at the DLSw endpoints in direct proportion to 
the number transport connections.   The DLSw Scalability group has identified 
two scenarios where the number of transport connections can become significant 
resulting in excessive overhead and corresponding equipment costs (in memory 
and CPU).   The first scenario is found in highly meshed DLSw configurations 
where the number of transport connections approximates n2 (where n is the 
number of DLSws).  This is typically found in DLSw networks supporting N
etBIOS.  The second scenario is found  in networks  where many remote locations 
communicate to few central sites.  In this case, the central sites must support 
n transport connections  (where n is the number of remote sites).    In both 
scenarios the resultant transport connection overhead is considered undesirable 
depending upon the value of n.   

z LLC2 overhead

RFC 1795 specifies that each DLSw provides local termination for the LLC2 (SDLC 
or other SNA reliable data link  protocol) sessions traversing the SSP.   
Because these reliable data links also provide guaranteed in order packet 
delivery, the memory and CPU overhead of  maintaining these connections can 
also become significant.   This is particularly undesirable in the second 
scenario described above.  This is because the number of reliable connections 
maintained at the central site is the aggregate of the connections maintained 
at each remote site.  

It is not the intent of this document to address all the undesirable 
scalability issues associated with RFC 1795.   This paper identifies protocol 
enhancements to RFC 1795 using the inherent multicast capabilities of the 
underlying transport network to improve the scalability of RFC 1795.   It is 
believed that the enhancements defined, herein,  will address many of the 
issues identified such as: administration, address resolution,  broadcast 
packets, and to a lesser extent transport overhead.   This paper will not 
address LLC2 overhead.   Subsequent efforts by the AIW and/or DLSw Scalability 
group may address the unresolved scalability issues.

While it is the intent of this paper to accommodate all transport protocols as 
best as is possible, it is recognized that the multicast capabilities of many 
protocols is not yet well defined, understood, or implemented. Since TCP is the 
most prevalent DLSw transport protocol in use today, the DLSw Scalability group 
has chosen to focus its definition around TCP based multicast services.  Within 
the protocol definitions, efforts will be made to accommodate the potential 
application of other transport multicast services as best as can be done at 
this time.  But this specification will only address the implementation detail 
of TCP based multicast services. 

This proposal does not consider the impacts of IPv6 as this was considered too 
far from widespread use at the time of writing.

Overview

This paper describes the use of multicast services within the transport network 
to improve the scalability of DLSw based networking.   There are only a few 
main components of this proposal:

z Single session TCP connections
 
 RFC 1795 defines a negotiation protocol for DLSws to chose either two 
unidirectional or one bi-directional TCP connection.    DLSws implementing the 
enhancements described in this document 
 must support and use(whenever required and possible)a single bi-directional 
TCP connection between DLSw peers. That is to say that the single tunnel 
negotiation support of RFC 1795 is a prerequisite function to this set of 
enhancements. Use of two unidirectional TCP connections is only allowed (and 
required)for migration purposes when communicating with DLSws that do not 
implement these enhancements.
 
 Note: The negotiation process and protocol state machines for single tunnel 
negotiation is described in RFC 1795.  Reference that document for further 
implementation detail.  
 
z TCP connections on demand
 
 Two DLSws will only establish a TCP connection when necessary.  SSP 
connections to DLSws which do not implement this enhancement are assumed to be 
established by means defined outside this paper.  DLSws implementing this 
enhancement utilize UDP based transport services to send address resolution 
packets (CANUREACH_ex, NETBIOS_NQ_ex, etc.).  If a positive response is 
received, then a TCP connection is only established to the associated DLSw peer 
if one does not already exist.  Correspondingly, TCP connections are brought 
down when there are no circuits to a partner DLSw for an implementation defined 
period of time. 
   
z Address resolution through UDP 
 
 The main thrust of this paper is to utilize non-reliable transport and the 
inherent efficiencies of multicast protocols whenever possible and applicable 
to reduce network overhead.  Accordingly, the address resolution protocols of 
SNA and NetBIOS are sent over the non-reliable transport of IP, namely UDP.  In 
addition, IP multicast services are used whenever address resolution packets 
must be sent to multiple destinations. This avoids the need to maintain TCP SSP 
connections between two DLSws when no circuits are active.  CANUREACH_ex and 
ICANREACH_ex packets can be sent to all the appropriate DLSw partners without 
the need for preconfigured peers or pre-established TCP/IP connections.  In 
addition, most multicast services (including TCPs MOSPF, DVMRP, MIP, etc.) 
replicate and propagate messages only as necessary to deliver to all multicast 
members.   This avoids duplication and excessive bandwidth consumption in the 
transport network.  
 
 To further optimize the use of WAN resources, address resolution responses are 
sent in a directed fashion (i.e., unicast) via UDP transport whenever 
possible.   This avoids the need to setup or maintain TCP connections when they 
are not required.  It also avoids the bandwidth costs associated with 
broadcasting. 
 
 Note: It is also permitted to send some address resolution traffic over 
existing TCP connections.  The conditions under which this is permitted are 
detailed in section 6.
 
z NetBIOS broadcasts over UDP

In the same manner as above, NetBIOS broadcast packets are sent via UDP 
(unicast and multicast) whenever possible and appropriate. This avoids the need 
to establish TCP connections between DLSws when there are no circuits 
required.   In addition, bandwidth in the transport network is conserved by 
utilizing the efficiencies inherent to multicast service implementation.  
Details covering identification of these packets and proper propagation methods 
are described in section 9.

Multicast Groups and Addressing 

IP multicast services provides an unreliable datagram oriented delivery service 
to multiple parties. Communications is accomplished by sending and/or listening 
to specific multicast addresses.  When a given node sends a packet to a 
specific address (defined to be within the multicast address range), the IP 
network (unreliably) delivers the packet to every node listening on that 
address.  

Thus, DLSws can make use of this service by simply sending and receiving (i.e., 
listening for) packets on the appropriate multicast addresses. With carefully 
planning and implementation, networks can be effectively partitioned and 
network overhead controlled by sending and listening on different addresses 
groups.  It is not the intent of this paper to define or describe the 
techniques by which this can be accomplished.  It is expected that the 
networking industry (vendors and end users alike) will determine the most 
appropriate ways to make use of the functions provided by use of DLSw multicast 
transport services.   

Using Multicast Groups

The multicast addressing as described above can be effectively used to limit 
the amount of broadcast/multicast traffic in the network.  It is not the intent 
of this document to describe how individual DLSw/SSP implementations would 
assign or chose group addresses.   The specifics of how this is done and 
exposed to the end user is an issue for the specific implementor.  In order to 
provide for multivendor interoperability and simplicity of configuration, 
however, this paper defines a single IP multicast address, 224.0.10.000, to be 
used as a default DLSw multicast address.  If a given implementation chooses to 
provide a default multicast address, it is recommended this address be used.  
In addition, this address should be used for both transmitting and receiving of 
multicast SSP messages.  Implementation of a default multicast address is not, 
however, required.

DLSw Message Transports

With the introduction of DLSw Multicast Protocols,  SSP messages are now sent 
over two distinct transport mechanisms:  TCP/IP connections and UDP datagrams.  
Furthermore, the UDP datagrams can be sent to two different kinds of IP 
addresses: unique IP addresses (generally associated with a specific DLSw), and 
multicast IP addresses (generally associated with a group of DLSws).   

Single Session TCP/IP Connections

RFC 1795 defines the use of two unidirectional TCP/IP sessions between any pair 
of DLSw partners using read port number 2065 and write port number 2067.  
Additionally, RFC 1795 allows for implementations to optionally use only one 
bi-directional TCP/IP session.  Using one TCP/IP session between DLSw partners 
is believed to significantly improve the performance and scalability of DLSw 
protocols.  Performance is improved because TCP/IP acknowledgments are much 
more likely to be piggy-backed on real data when TCP/IP sessions are used 
bi-directionally.  Scalability is improved because fewer TCP control blocks, 
state machines, and associated message buffers are required.  For these 
reasons, the DLSw enhancements defined in this paper REQUIRE the use of single 
session TCP/IP sessions.  

Accordingly, DLSws implementing these enhancements must carry the TCP 
Connections Control Vector in their Capabilities Exchange.  In addition, the 
TCP Connections Control Vector must indicate support for 1 connection.  

TCP Connection establishment sequences and state machines remain the same as 
defined in RFC 1795.  As an optional enhancement, however, multicast capable 
DLSw nodes may chose not to establish a second TCP connection (local port 
2067)upon receipt of a TCP connection indication from another multicast capable 
DLSw partner (as indicated in the received Capabilities Exchange message).  In 
this case, the receiving DLSw simply responds with its capabilities over the 
newly established TCP connection.

TCP/IP Connections on Demand

As is the case in RFC 1795, TCP/IP connections are established between DLSws.  
Unlike RFC 1795, however, TCP/IP connections are only established to carry 
reliable circuit data (i.e., LLC2 based circuits).  Accordingly, a TCP/IP 
connection is only established to a given partner DLSw when the first circuit 
to that DLSw is required (i.e., the origin DLSw must send a CANUREACH_CS to a 
target DLSw partner and there is no existing TCP connection between the two).  
In addition, the TCP/IP connection is brought down an implementation defined 
amount of time after the last circuit has terminated.  In this way, the 
overhead associated with maintaining TCP connections is minimized.  

Note: Non-circuit based SSP packets (e.g.,CANUREACH_ex, etc.) may still be 
sent/received over TCP connections after all circuits have been terminated.  
Taking this into account implementations should still gracefully terminate 
these TCP connections once the connection is no longer supporting circuits. 
This may require an implementation to retransmit request frames over UDP when 
no response to a TCP based unicast request is received and the TCP connection 
is brought down.  This is not required in the case of multicast requests as 
these would be received over the multicast transport mechanism.  

UDP Datagrams

As mentioned above, UDP datagrams can be sent two different ways: unicast 
(e.g., sent to a single unique IP address) or multicast (i.e., sent to an IP 
multicast address).  Throughout this document, the term UDP datagram will be 
used to refer to SSP messages sent over UDP, while unicast and multicast SSP 
messages will refer to the specific type/method of UDP packet transport.   In 
either case, standard UDP services are used to transport these packets.  In 
order to properly parse the inbound UDP packets and deliver them to the SSP 
state machines, all DLSw UDP packets will use the destination port of x2065. 
In addition, the checksum function of UDP remains optional for DLSw SSP 
messages.  It is believed that the inherent CRC capabilities of all data link 
transports will adequately protect SSP packets during transmission.  And the 
incremental exposure to intermediate nodal data corruption is negligible.  For 
further information on UDP packet formats see section 11.

UDP SSP Packet Handling  

In order to accommodate future AIW and vendor specific enhancements, 
implementations must ignore unrecognized packets (or unrecognized portions 
thereof)when received over the UDP transport (unicast or multicast).  A packet 
is considered to be unrecognized if it does not adhere to the defined SSP 
format listed in RFC 1795 or this document.  A portion of a packet is 
considered to be unrecognized if it contains undefined subvectors in properly 
defined positions.  In this case, those portions of the packet that are 
recognized should be honored and processed accordingly.  Those portions which 
are unrecognized should be ignored. 

Unicast UDP Datagrams

Generically speaking, a unicast UDP datagram is utilized whenever an SSP 
message (not requiring reliable transport) must be sent to a unique DLSw and a 
TCP connection to that peer does not yet exist.  This avoids the overhead of 
having to establish and maintain TCP connections when they are not required for 
reliable data transport. If, however, a TCP connection to the destination DLSw 
peer does exists, then the SSP packet should be sent over this connection.  
This avoids the possibility packet loss due to the unreliable nature of UDP 
transport. 

Note: This only applies to unicast packets (not multicast).  If multicast 
packets were sent over TCP connections (when they existed), then multicast 
capable DLSws would tend to receive packets twice, once over the multicast 
service and once over TCP.  This is because the sender would have to send the 
SSP message over both services to ensure reaching all peer DLSws (TCP only 
would not be sufficient).

A typical example of when unicast UDP might be used would be 
an ICANREACH_ex response from a peer DLSw (with which no TCP connection 
currently exists).  In this case, the sending DLSw knows the IP address of the 
intended receiver and can simply send the response via unicast UDP.   In 
addition, there are a number of NetBIOS cases where unicast UDP is used to 
handle UI frames directed to a specific DLSw (e.g., STATUS_RESPONSE).   Further 
detail is provided  in the NetBIOS section of this document.  

Multicast UDP Datagrams

In a broad sense, multicast UDP datagrams are used whenever a given SSP message 
must be sent to multiple DLSw peers.  In the case of SNA, this is primarily the 
CANUREACH_ex packets.  In the case of NetBIOS, multicast datagrams are used to 
send all broadcast UI frames including NetBIOS user datagrams and broadcast 
datagrams.  

Note, however, it is sometimes possible to avoid broadcasting certain NetBIOS 
frames that would otherwise be broadcast in the LAN environment.  This is 
typically accomplished using name caching techniques not described in this 
paper.  In cases of this type when a single destination DLSw can be determined, 
unicast transport can be used to send the broadcast NetBIOS frame to a single 
destination.  A more detailed listing of NetBIOS SSP packets and transport 
methods can be found in the NetBIOS section of this document.

Unicast UDP Datagrams in Lieu of IP Multicast 

Because the use of IP multicast services is actually a function of IP itself 
and not DLSw proper, it is possible for implementations to simply make use of 
the UDP transport mechanisms described in this paper without making direct use 
of the IP multicast function.  While this is not considered to be as efficient 
as using multicast transport mechanisms, this practice is not explicitly 
prohibited.  Implementations which chose to make use of  UDP transport in this 
manner must first know the IP address of all the potential target DLSws and 
send individual unicast packets to each.  How this information is obtained 
and/or maintained is outside the scope of this paper.  

Migration Support

It is anticipated that some networks will experience a transition stage where 
both RFC 1795 (referred to as back-level DLSws) and enhanced RFC 1795 DLSws 
(those implementing these enhancements, referred to as up-level DLSws) will 
exist in the network at the same time.  It will be important for these two DLSw 
node types to interoperate and thus the following accommodations for back-level 
DLSws are required: 

Capabilities Exchange

In order to guarantee both backward and forward capability, DLSws which 
implement these multicast enhancements will carry a Multicast Capabilities 
Control Vector in their capabilities exchange (see RFC 1795 for an explanation 
of capabilities exchange protocols).   Presence of the Multicast Capabilities 
control vector indicates support for the protocols defined in this document on 
a per DLSw partner basis.  Conversely, lack of the Multicast Capabilities 
control vector indicates no support for these extensions on a per DLSw partner 
basis.  

In addition, presence of this control vector mandates a TCP Connections Control 
Vector indicating support for 1 TCP connection in the same Capabilities 
exchange.  

Connecting to down-level nodes

It is assumed that TCP connections to DLSws which do not support multicast 
services are established by some means outside the scope of this paper (i.e., 
non-multicast partner addresses are configured by the customer).   TCP 
connections must be established and maintained to down level nodes in the exact 
same manner as RFC 1795 requires, establishes, and maintains them.  And because 
down-level DLSws will not indicate support for multicast services in their 
capabilities exchange, an up-level DLSw will know all its down-level peers. 

Communicating with down-level nodes 

Because down-level nodes will not receive SSP frames via UDP (unicast or 
multicast) transmission, SSP messages to these DLSws must be sent over TCP 
connections to the down-level nodes.   Therefore, nodes which implement the 
multicast protocol enhancements must keep track of which DLSw partners do not 
support multicast extensions (as indicated in the capabilities exchange).  When 
a given packet is sent out via multicast services, it must also be sent over 
multicast UDP(to reach other up-level DLSws) and over the TCP connection to 
each down-level node.   And although the multicast service requires periodic 
retransmissions (for reliability reasons), this is not the case with TCP 
connections to down-level nodes. Therefore, up-level DLSws should not resend 
SSP packets over TCP transport connection but rather, rely upon TCP to recover 
any lost packets. Furthermore, communications with down-level nodes should be 
in exact compliance with RFC 1795 protocols.  

When sending a unicast UDP message, it is important to know that the 
destination DLSw supports multicast services.  This knowledge can be obtained 
from previous TCP connections/capabilities exchanges or inferred from a 
previously received UDP message.   In practice, this should not present a 
problem as UDP messages are only sent in response to a multicast base request 
or for UI frames when the local cache has information correlating the 
destination LSAP with some specific DLSw.  In the latter case, if the DLSw is 
down-level, then there would be a TCP connection to it and it would be known to 
be down-level.  If it is not down-level and a TCP connection is in existence, 
then its level is known (via the prior capabilities exchange).  If it is not 
down-level and there is not an existing TCP connection, then it can be implied 
to be up-level (by lack of a TCP connection)by virtue of a cached entry but no 
active TCP connection (e.g., TCP peer on demand support).  This inference, 
however, could be erroneous in cases where the TCP connection (to a down-level 
DLSw) has failed for some reason. But normal UDP based unicast verification 
mechanisms will detect no active path to the destination and circuit setup will 
proceed correctly (i.e., succeed or fail inaccordance with true connectivity). 

Note: 
When two up-level DLSws have a established  TCP connection, unicast SSP packets 
should be exchanged over the TCP connection. Multicast SSP messages should be 
sent over UDP multicast services.  TCP connections between up-level DLSws are 
only used for reliable (LLC2) circuit setup, circuit I-frame data, circuit 
takedown, and SSP packets specifically for that peer.   

SNA Support 

In SNA protocols the generalized packet sequence of interest is a test frame 
exchange followed by an XID exchange.   The following paragraphs describe how 
multicast protocol enhancements are used to establish SNA data links.

Note: This paper does not attempt to address the unique issues presented by 
SNA/HPR and its non-ERP data links

Address Resolution

When a DLSw receives an incoming test frame from an attached data link, the 
assumption is that this is an exploratory frame in preparation for an XID 
exchange and link activation.  The DLSw must determine a correlation between 
the destination LSAP (mac and sap pairing) and some other DLSw in the transport 
network.   This paper generically refers to this process as address resolution. 

Explorer frames

Unicast (i.e., sent to only one destination) CANUREACH_ex, ICANREACH_ex, NQ_ex 
and NR_ex messages may be sent over a TCP connection to an up-level partner if 
such a connection already exists in order that they take advantage of the 
guaranteed delivery of TCP.  This is particularly recommended for ICANREACH_ex 
and NAME_RECOGNIZED_ex frames where the guaranteed delivery of TCP avoids the 
need to send unicast retries for these responses.

Note: It is an absolute requirement that all V2 DLSw implementations support 
multicast.  It is not permitted to send CANUREACH_ex and ICANREACH_ex over TCP 
pipes that have been brought up solely for this purpose as this is precisely 
the scalability issue we are trying to solve.

Example SNA SSP Message Sequence 

The following diagram provides an example sequence of flows associated with an 
SNA LLC circuit setup.    All flows and states described below correspond 
precisely with those defined in RFC 1795.  The only exception is the addition 
of a TCP connection setup and DLSw capabilities exchange that occurs when the 
origin DLSw must send a CANUREACH_CS and no TCP connection yet exists to the 
target DLSw partner.  

 ======                            ___                           ======
 |    |        ---------        __/   \__       ---------        |    |
 |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
 ======        |   |   |      <  Network  >     |   |   |        ======
/______\       ---------       \__     __/      ---------       /______\
 Origin       Origin DLSw         \___/        Target DLSw      Target
 Station        partner                          partner        Station

              disconnected                    disconnected

TEST_cmd      DLC_RESOLVE_C    CANUREACH_ex               TEST_cmd
----------->  ----------->     ----------->               ---------->
   TEST_rsp   DLC_RESOLVE_R    ICANREACH_ex                 TEST_rsp
 <---------    <-----------   <-----------                <----------
null XID      DLC_XID
----------->  ----------->
              circuit_start

     TCP Connection Setup
     <------------->
     Capabilities Exch.
     <------------->
      CANUREACH_cs    DLC_START_DL
          ----------->     ----------->
            resolve_pending
                                ICANREACH_cs    DLC_DL_STARTED
                                <-----------    <-------------
           circuit_established                circuit_pending
                              REACH_ACK
                              ----------->  circuit_established

                              XIDFRAME         DLC_XID       null XID
                              ----------->     --------->    -------->
        XID        DLC_XID        XIDFRAME         DLC_XID          XID
  <--------   <-----------    <-----------    <-----------    <--------
    XIDs         DLC_XIDs      XIDFRAMEs        DLC_XIDs         XIDs
<---------->  <---------->  <------------>  <------------>  <--------->
SABME         DLC_CONTACTED   CONTACT         DLC_CONTACT     SABME
----------->  ----------->    ----------->    ----------->    -------->
              connect_pending                 contact_pending

          UA     DLC_CONTACT     CONTACTED    DLC_CONTACTED          UA
  <---------   <-----------   <-----------    <-----------    <--------
                  connected                        connected
IFRAMEs       DLC_INFOs        IFRAMEs        DLC_INFOs       IFRAMEs
<---------->  <----------->  <------------>  <------------>  <-------->

Circuit Setup  

Circuit setup is accomplished in the same manner as described in RFC 1795.  
More specifically, CANUREACH_cs, ICANREACH_cs, REACH_ACK, XIDFRAME, etc. are 
all sent over the TCP connection to the appropriate DLSw.   This, of course, 
assumes the existence of a TCP connection between the DLSws.   If the sending 
DLSw (sending a CANREACH_cs ) detects no active TCP connection to the partner 
DLSw, then a TCP connection setup is initiated and the packet sent.  All other 
circuit setup (and takedown) related sequences are now passed over the TCP 
connection. 

UDP Reliability 

It is important to note, that UDP (unicast and multicast)transport services do 
not provide a reliable means of delivery.  Existing RFC 1795 protocols 
guarantee the delivery (or failure notification) of CANUREACH_ex and 
ICANREACH_ex messages.  UDP will not provide the same level of reliability.  It 
is, therefore, possible that these messages may be lost in the network and 
retries will be necessary.  

Retries 

Test Frames are generally initiated by end stations every few seconds.  Many 
existing RFC 1795 DLSw implementations take advantage of the reliable SSP TCP 
connections and filter out end station Test frame retries when a CANUREACH_ex 
is outstanding.   Given the unreliable nature of UDP transport for these 
messages, however, this filtering technique may not be advisable.  Neither RFC 
1795 or this paper address this issue specifically.  It is simply noted that 
the UDP transport mechanism is unreliable and implementations should take this 
into account when determining a scheme for Test frame filtering and explorer 
retries.

NetBIOS

With the introduction of DLSw Multicast transport, all NetBIOS UI frames are 
carried outside the TCP connections between DLSws (i.e., via UDP datagrams).   
The following table defines the various NetBIOS UI frames and how they are 
transported via UDP between multicast capable DLSws:

                         Transport
Message Event   Action   Mechanism   Retry
---------------------------------------------------------------------------------------
ADD_GROUP_NAME_QUERY  SEND DATAFRAME  Multicast Yes  
ADD_NAME_QUERY   SEND NETBIOS_ANQ Unicast/Multicast Yes
ADD_NAME_RESPONSE   Send NETBIOS_ANR  Unicast1 Yes
NAME_IN_CONFLICT   SEND DATAFRAME  Multicast Yes
STATUS_QUERY   SEND DATAFRAME  Multicast2   
TERMINATE_TRACE (x07)  SEND DATAFRAME  Multicast 
TERMINATE_TRACE (X13)  SEND DATAFRAME  Multicast 
DATAGRAM    SEND DATAFRAME Unicast/Multicast3
DATAGRAM_BROADCAST  SEND DATAFRAME  Multicast
NAME_QUERY    SEND NETBIOS_NQ_ex Multicast2  Yes
NAME_RECOGNIZED   Send NETBIOS_NR_ex Unicast4   Yes 
STATUS_RESPONSE   Send DATAFRAME  Multicast5 Yes

Note 1:
Upon receipt of an ADD_NAME_RESPONSE frame, a NETBIOS_ANR SSP message is 
returned via unicast UDP to the originator of the NETBIOS_ANQ message. If, 
however, a TCP connection to that partner exists, the message should be sent 
over the TCP connection.

Note 2:
STATUS_QUERY and NAME_QUERY frames may be sent ARB or SRB on the LAN.  However, 
these frames should always be multicast on the WAN.  This ensures that when the 
location of a NetBIOS resource is not known, the query reaches all up-level 
DLSw implementations with minimum WAN traffic (though, in a migration case, it 
may still be necessary for the originating DLSw to send the frame over TCP to 
each down-level DLSw partner separately).

Note 3:
DATAGRAM frames may be sent either Unicast or Multicast UDP.  If the 
implementation has sufficient cached information to resolve the NetBIOS 
datagram destination to a single DLSw peer, then the SSP message can and should 
be sent via unicast (with the understanding that via TCP is preferred should 
such a connection exist).  If the cache does not contain such information then 
the resultant SSP message must be sent via multicast UDP.  Note that this frame 
is sent as either a DATAFRAME or DGRMFRAME according to the rules as specified 
in RFC 1795. 

Note 4:
Upon receipt of a NAME_RECOGNIZED frame, a NETBIOS_NR_ex SSP message is 
returned via unicast UDP to the originator of the NETBIOS_NQ_ex frame.  Notice 
that although the NAME_RECOGNIZE frame is sent as an ARE (source routing LANs 
only) frame, the resultant NETBIOS_NR_ex is sent as a unicast UDP directed 
response to the DLSw originating the NETBIOS_NQ_ex.   This is because there is 
no value in sending NETBIOS_NR_ex as a multicast packet in the transport 
network.  The use of ARE transmission in the LAN environment is to accomplish 
some form of load sharing in the source routed LAN environment.  Since no 
analogous capability exists in the (TCP) transport network, it is not necessary 
to emulate this function there.   It is important to note, however, that when co
nverting a received NETBIOS_NR_ex to a NAME_RECOGNIZED frame, the DLSw sends 
the NAME_RECOGNIZED frame onto the LAN as an ARE (source routing LANs only) 
frame.  This preserves the source route load sharing in the LAN environments on 
either side of the DLSw transport network.  

Note 5:
Although RFC 1795 does not attempt to optimize STATUS_RESPONSE processing, it 
is possible to send a STATUS_RESPONSE as a unicast UDP response.  To do this, 
DLSws receiving an  incoming STATUS_QUERY must remember the originating DLSws 
address and STATUS_QUERY correlator.  Then upon receipt of the corresponding 
STATUS_RESPONSE, the DLSw responds via unicast UDP to the originating 
DLSw(using the remembered originating DLSw address). Note, however, that in 
order  to determine whether a frame is a STATUS_QUERY, all up-level DLSw 
implementations will need to parse the contents of frames that would normally 
be sent as DATAFRAME SSP messages.  

All other multicast frames are sent into the transport network using the 
appropriate multicast group address. And all unicast messages should be sent 
over a TCP connection in preference to UDP when TCP connection already exists.  

Address Resolution

Typical NetBIOS circuit setup using multicast services is  essentially the same 
as specified in RFC 1795.   The only significant difference is that 
NETBIOS_NQ_ex messages are sent via UDP to the appropriate multicast IP address 
and the NETBIOS_NR_ex is sent via unicast UDP to the DLSw originating the 
NETBIOS_NQ_ex.

Circuit Setup 

Following successful address resolution, a NetBIOS end station typically sends 
a SABME frame to initiate a formal LLC2 connection.   Receipt of this message 
results in  normal circuit setup as described in RFC 1795 (and the SNA case 
described above).  That is to say that the CANUREACH_cs messages etc. are sent 
on a TCP connection to the appropriate partner DLSw.  If no such TCP connection 
exists, one is brought up. 

Example NetBIOS SSP Message Sequence

The following diagram provides an example sequence of flows associated with a 
NetBIOS circuit setup.    All flows and states described below correspond 
precisely with those defined in RFC 1795.  The only exception is the addition 
of a TCP connection setup and DLSw capabilities exchange that occurs when the 
origin DLSw must send a CANUREACH_CS and no TCP connection yet exists to the 
target DLSw partner.  

 ======                            ___                           ======
 |    |        ---------        __/   \__       ---------        |    |
 |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
 ======        |   |   |      <  Network  >     |   |   |        ======
/______\       ---------       \__     __/      ---------       /______\
 Origin       Origin DLSw         \___/        Target DLSw      Target
 Station        partner                          partner        Station

              disconnected                     disconnected

NAME_QUERY    DLC_DGRM        NETBIOS_NQ_ex   DLC_DGRM       NAME_QUERY
----------->  ----------->    ----------->    ----------->   --------->

   NAME_RECOG    DLC_DGRM      NETBIOS_NR_ex     DLC_DGRM    NAME_RECOG
 <-----------  <------------   <-----------    <-----------  <---------

SABME         DLC_CONTACTED   
----------->  ----------->    
               circuit_start   

     TCP Connection Setup
     <------------->
     Capabilities Exch.
     <------------->
      CANUREACH_cs    DLC_START_DL
      ----------->    ----------->
          resolve_pending

                                ICANREACH_cs    DLC_DL_STARTED
                                <-----------    <-----------
            circuit_established                circuit_pending
                              REACH_ACK
                              ----------->   circuit_established

                              CONTACT         DLC_CONTACT     SABME
                              ----------->    ----------->    --------->
             connect_pending                 contact_pending

          UA   DLC_CONTACT       CONTACTED    DLC_CONTACTED           UA
  <---------  <-----------    <-----------    <-----------    <---------
                connected                       connected

   IFRAMEs       DLC_INFOs       IFRAMEs        DLC_INFOs       IFRAMEs
<------------> <------------> <------------>  <------------>  <-------->

Multicast Reliability and Retries

In the case of NetBIOS, many more packets are being sent via UDP than in the 
SNA case.  Therefore, the exposure to the unreliability of these services is 
greater than that of SNA.   For NetBIOS frames that are not part of address 
resolution, such as STATUS_QUERY/RESPONSE and DATAGRAMs, this is not considered 
an issue and no retry is required.  For address resolution frames, such as 
NAME_QUERY, etc., successful message delivery is more of an issue.   In 
addition, the retry interval for these types of frames is considerably shorter 
than SNA with the defaults being:  retry interval = 0.5 seconds and retry count 
= 6.   Once again, neither RFC 1795 or this paper attempt to address the issue 
of LAN frame filtering optimizations. This issue is outside the scope of this 
paper.  But it is important for implementers to recognize the inherent 
unreliable nature of UDP transport services for frames of this type and to 
implement retry schemes that are appropriate to successful operation.  Specific 
NetBIOS messages where successful message delivery is considered important are 
indicated in the table above with an Yes in the Retry column.
Sequencing 

It is important to note that UDP transport services do not provide guaranteed 
packet sequencing like TCP does for RFC 1795.  In a steady state network, in 
order packet delivery can be generally assumed.   But in the presence of 
network outages and topology changes, packets may take alternate routes to the 
destination and arrive out of sequence with respect to their original 
transmission order.    For SNA address resolution this should not be a problem 
given that their is no inherent significance to the order of packets being 
transmitted via UDP.   

In the case of NetBIOS, in order delivery is not guaranteed in the normal case 
(e.g., LANs).  This is because LAN broadcasting mechanisms suffer the same 
problems of packet sequencing as do wan multicast mechanisms.   But one might 
argue the greater likelihood of topology related changes in the wan environment 
and thus a greater level of concern.  The vast majority of NetBIOS UI frames 
(being handled via UDP and Multicast) have correlator values and do not rely 
upon packet sequencing. 

The only NetBIOS frames of special note would be: DATAGRAM, DATAGRAM_BROADCAST, 
and STATUS_RESPONSE.  In the case of DATAGRAM and DATAGRAM_BROADCAST it is 
generally assumed that datagrams do not provide any guarantee of in order 
packet delivery.  Thus applications utilizing this NetBIOS service are assumed 
to have no dependency on in order packet delivery.   STATUS_RESPONSE can 
actually be sent as a sequence of STATUS_RESPONSE messages.  In cases where 
this occurs, the STATUS_RESPONSE will be exposed to potential out of sequence 
delivery. 

Frame Formats

Multicast Capabilities Control Vector

This control vector is carried in the Capabilities Exchange Request.  When 
present, it must be accompanied by a TCP Connections Control Vector indicating 
support for 1 TCP/IP connection.  Like all control vectors in this SSP message, 
it is an LT structure.  LT structures consist of a 1 byte length field followed 
by a 1 byte type field.   The length field includes itself as well as the type 
and data fields.  

Byte Bit  Description
0 0-7  Length, in binary, of the multicast capabilities control        vector 
(inclusive of this byte)

1 0-7  Type:  x8C 

2 0-7  Multicast Version Number: 
 A binary numerical representation of the level of multicast services   
provided.  The protocols as identified in this document constitute version  
one.   Accordingly, x01 is encoded in this field.  Any subsequent version  must 
provide the services of all previous versions.

3-4   Reserved 

5-n   Optional Control Vectors: parsed LT if present.          Currently, none 
defined. 

The intended use of this CV for Multicast support is to detect when the 
multicast CUR_ex flows will suffice between partners.  If this CV is present in 
a cap-ex from a partner, that partner is also up-level and therefore does not 
need to receive CUR_ex messages over the TCP link  that exists between them 
(and there must be one or else the cap-ex would not have flowed) because it 
will receive the multicast copies. 

A DLSw includes this control vector on a peer-wise basis.  That is to say, that 
a DLSw implementation may support multicast services but choose not to indicate 
this in its capabilities exchange to all partners. Therefore, a DLSw may 
include this capabilities CV with some DLSw peers and not with others.  Not 
including this vector can be used to force TCP connections with other up-level 
nodes and degrade to normal RFC 1795 operations.  This capability is allowed to 
provide greater network design flexibility.  

All DLSws implementing these enhancements must quietly ignore any unrecognized 
optional CVs in bytes 5 onwards.  If a Multicast capabilities CV is received 
containing unrecognized optional CVs, the receiving DLSw must not reject the 
capabilities exchange for this reason (though it is permitted to reject the 
cap-ex with a negative response if the vector is badly formatted or if there 
are other errors in the cap-ex).

UDP Packets

SSP frame formats are defined in RFC 1795.  Multicast protocol enhancements do 
not change these formats in any way.  The multicast protocol enhancements, 
however, do introduce the notion of SSP packet transport via UDP.  In this 
case, standard UDP services and headers are used to transport SSP packets. 

The following section describes the proper UDP header for DLSw SSP packets.

Byte Bit  Description
0-1   Source Port address
 In DLSw multicast protocols, this particular field is not relevant.  It  may 
be set to any value.

2-3   Destination Port address
   Always set to x2065 

4-5   Length

6-7   Checksum  
 The standard UDP checksum value.  Use of the UDP checksum function is   
optional.